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Abstract 
This article shows the current status and updates the progress and accomplishments since 
the last published article in 1990 [I], of Texas Packet Radio Society, TexN et network, and 
other projects. The topics for this update cover the growth of the organization, the 
expansion of the network, the reliability aspects of the network, the latest firmware, and 


continuing projects. 


Texas Packet Radio Society 


TPRS was founded in 1985, and 
incorporated in 1986 as an educational, 
public service, and scientific research non- 
profit corporation. The Texas Packet Radio 
Society’s goals are: 1) design and research 
amateur radio packet networks, 2) provide 
education in the area of general packet 
usage, and 3) provide an emergency 
communication service network. The 
organization has members throughout 
Texas, many states, and several foreign 
countries and has had good growth since 
1990. Membership in TPRS is now above 
500 members. 


TPRS itself does not support individual 
nodes per se, except for a few exceptions, 
like NWS, which serve the whole network. 
Individual nodes are the responsibility of 
local support. TPRS does arrange for 
support of certain projects (Such as donated 
wire line or facilities) which are used to tie 
critical parts of the network together. This 
approach has been very successful in 
network management. In addition, the level 
of expertise required to build, install, and 
keep a network node running has provided 
a level of selection that has proved beneficial. 
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TexN et Network Expansion 


Figure 1 shows the TexNet network map, 
which has now grown to include four states. 
The northern part of the network reaches 
into Missouri, in the vicinity of Aurora in 
the southwest part of the state. The network 
has also pushed all the way northeast to 
Little Rock, Arkansas, and northwest to the 
metro outskirts of Oklahoma City, at 
Choctaw. The southern boundary of the 
network is the Rio Grande River in the Texas 
lower valley. Cooperating organizations in 
adjoining states supporting this network 
include HogNet in Arkansas, OARS in 
Missouri, and WopNet in the Valley of 
Texas. Individual nodes are supported 
locally by individuals and organizations, 
and TPRS performs network administration, 
coordination, and management. Nodes 
continue to be added from time to time, and 
further expansions are being planned or are 
under construction. Approximately fifty full 
time service nodes are on the air at present, 
with a few more used for development, 
testing or construction. 
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Mileage spanned by the network trunks is phenomenal for an amateur packet network 
and breaks down as follows: 


UHEF RF amateur radio 9600b fsk 1559 miles 53% 
VHE RF amateur radio 1200b afsk 147 miles 5% 
Donated carrier wire line 1253 miles 42% 
Network total trunk mileage 2959 miles 
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The above mileages are point to point 
from site to site statute miles for active 
operating sites, as of 1995. In the case of the 
donated wire line circuits, city center 
highway mileages were used, and the 
various carriers deviate from these paths 
considerably, making the actual circuit 
mileages higher by some uncalculated 
amount. The network includes metropolitan 
coverage into three state capital cities - 
Austin, Texas, Little Rock, Arkansas, and 
Oklahoma City, Oklahoma. 


End-to-end turnaround time from 
opposite ends of the network (800 miles), 
during times of relative network inactivity 
and smooth operation, are on the order of 
15 to 30 seconds. Anything in excess of 
about 90 seconds indicates a problem in 
network operations. The network is not 
immune toproblems of various kinds. Tom 
McDermott, N5EG, has gone into detail 
about the reliability of hop-by-hop 
networking with networks of smaller size 
and fewer nodes [2]. 


The user base of TexNet is composed of 
BBS forwarding, DX Cluster interconnections, 
real user-to-user keyboard contacts (some of 
which may use a network conference 
bridge), message servers for network users, 
Skywarn spotters and local EOCs, and 
network experimenters. The higher speed 
trunking (9600 baud) allows actual keyboard 
user contacts over wide distances. One of 
the reasons for the long standing decline and 
disuse of packet for keyboard contacts are 
the long response times typically observed 
on packet across the nation. | have 
personally participated in keyboard contacts 
spanning 500 miles or more on TexNet 
which were conversational and not painfully 
slow. 


Network Challenges and Reliability 


The usual challenges and setbacks in 
operating a network are the month-to- 
month repair of occasional failures of nodes 
due to catastrophic events such as lightning 
damage, or moving of nodes from one site 
to another in search of more amiable 
“landlords.” TexNet has had problems 
keeping a site active in order to extend the 
network between Oklahoma and Texas 
across the Red River. For over the last year, 
the north and south parts of the network 
have had to operate independently until a 
new network site can be located and brought 
on-line. Sometimes, we lose a site here and 
there, and have to regroup and look 
elsewhere. Meanwhile, the network is 
broken in the middle. So has been our luck 
over the vears at the small minoritv of sites 
where we have had these problems.’Overall, 
we have enjoyed a good-record of keeping 
all of the sites intact, and some lesser degree 
of luck at keeping lightning and surges out 
of the equipment. 


A major disturbance to network 
operations that occurs from time to time in 
South Texas (San Antonio, Texas south) is 
the operations of airborne radar. The 70cm 
amateur band is a secondarv allocation for 
amateurs with the prim&y allocation 
assigned to government radiolocation. In 
this case, this takes the form of the airborne 
radar being used in the last few years to 
intercept drug smuggling in the Gulf of 
Mexico. From time-to-time on an 
intermittent basis, this portion of the 
network is interrupted by radar interference. 
Most of the time the network stays intact, 
and only a minority of the time is the 
network affected. 


Another factor in network performance is 
maintaining the trunk radios on frequency. 
Network operators have done a good job of 
putting 9600 baud FSK into the field and 
making it work well, which it has most of 
the time, since 1984. The one detractor from 
that, which has earned the network a 


“fragile” reputation, is keeping the UHF 
radios inside a very tight frequency 
tolerance. Network node owners have to 
keep their radios on frequency with a lot of 
sites and few site visits to spare each year. 
Thus we expect the network to hold up 
through both summer heat and winter cold 
at some sites. 


We deal with a signal that is almost too 
tight for the I.F. filters in the radios to pass. 
It does fit just fine if the radio stays within a 
few hundred cycles of where it is supposed 
to be, but this is a tall order at UHF and 
requires tighter tolerance than the 
equipment was specified for when it was 
designed for two-way voice service. 
Throughout all of our design and 
construction we have resisted the urge to 
remove I.F. filters, as some 9600baud 
conversions have done, because of the 
introduction noise. We know from 
experience that the network runs very well 
if the frequency is kept under control. 


Yes, we DC couple, all the way from the 
modulator, through the transmitter and the 
channel and the receiver, through the 
modem to the slicer, for a better error rate. 
This does place more stress on the frequency 
control. As long as the node can hold 
frequency, the result is a better error rate at 
the slicer. Note, that in contrast to some 
other 9600baud packet methods in use 
today, TexNet uses pseudorandom 
scrambled NRZ, as opposed to NRZI, for 
tighter bandwidth, which does allow the 
network to achieve excellent performance 
with existing narrow filters with the 
commercial 5 KHz voice deviation two-way 
commercial land-mobile radio equipment 
being used. Deviation for data is set to 
approximately 3 KHz. 


We have found it necessary to “age” brand 
new crystals which we receive from 
reputable suppliers. This was never much 
of a concern with the same equipment and 
suppliers in voice service. There has been 
some debate concerning whether the 


manufacturing practices of the crystal 
industry have changed in the past few years, 
possibly due to such things as solvents being 
discontinued and the like. New crystals are 
operated at elevated temperatures for a few 
days or weeks prior to installing them, and 
even then we see drift in the first year of 
operation, usually requiring readjustment at 
varying intervals. 


In an effort to find a better solution to 
frequency control over the winter season 
change, it was found a one component 
temperature regulator (the positive 
coefficient thermistor) would work when 
attached to the crystal can or the channel 
element. When fed with 12 volts DC the 
thermistor holds the element within a few 
degrees of approximately 30 Deg. C. Most 
of the main trunk radios in Oklahoma now 
have them and have shown good results. 


Network Radios and M odems 


Over the past few years, our technical 
developers have experimented with various 
surplus two-way radio makes and mode's 
to see which are most suited for use in 9600b 
FSK service in the remote site environment 
we frequently encounter. The original 
surplus radio of choice was the RCA modded 
706. Since then, we have tried several 
Motorola, GE, and Johnson models. As a 
general rule, we have found a true 
discriminator to be superior to anything 
using a quadrature detector, and we have 
found some quadrature detectors to be 
better than others. The radio of choice in 
the Oklahoma environment has become the 
Motorola Micor. The Motorola Mocom-70 
has seen some use also. The Johnson 6060 
has seen some use in Texas. We have had 
some reliability problems with the venerable 
RCA-700, due to the failure of some PA 
components for which replacements are not 
available. Some of the newer model radios 
we have tested have a coupling capacitor 
downstream of the detector, and we find 
these models to be problematic with end- 
to-end DC coupled network. 
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We use one, and only one, RC time 
constant in the entire FSK signal path, and 
it is in the slicer of the modem receiver, and 
its time constant is optimized for the time 
required to acquire the received packet’s DC 
center. Any other unintended series RC 
circuit along the way contributes to baseline 
“wander,” and ultimately to receive errors. 
Any RC network which is part of an original 
voice radio design is almost certainly NOT 
optimized for the proper time constant 
anyway. Very recently, Tom McDermott, 
N5EG, has developed and is testing a newer 
improved slicer, which is a lot faster and 
more accurate than the one we now have. It 
seems to be a promising deveopment. If 
successful, it will take the form of a 
daughterboard for the existing TPRS 
modem. It locates both extremes of the 
received signal eye pattern, and sets itself 
midway a lot faster than the older, simpler 
RC averaging comparator. It might allow 
the network to operate with a shorter 
TxDelay timer. 


Network Code Continuing 
Development and Revisions 


Version 1.6x was just coming into use at 
the last CNC report in 1990 [ 11. This version 
was our standard firmware on the network 
from 1990 through 1993, and was a pretty 
well behaved product. This version of the 
code showed excellent performance and 
reliability. Previous versions were subject 
to dropping into a state of disconnection 
when the network was idle. Currently 
things stay connected as long as the path is 
there. Unfortunately, it works too well at 
times. During times of abnormally long 
range UHF propagation (up to 500 miles in 
one hop), the network forms rogue routes 
which do the network no good, and of 
course, don’t last. They certainly disrupt the 
shortest path algorithm and leave the 
routing tables in disarray. This 
phenomenon continues to the present, but 
we are on the verge of solving most of this 
problem with the next version (v1.72), 
currently in distribution. 


Version 1.70 was introduced in 1993. 
Primarily it is version 1.6x, with the routing 
tables expanded from 50 nodes to 90, and a 
few cosmetic changes. Version 1.71 was 
almost the same, but had a minor bug fixed 
with the DWAIT timer, and allowed for 
improved performance on shared channel's, 
such as a multidropped wire line circuit we 
use in West Texas. It has all of the 
characteristics of the 1.6x versions when it 
comes to adaptive routing and the 
corruption of its tables when the band opens. 
Another change is that the NCP and TNC-2 
versions of the code are now handled as a 
pair of similar products, and are updated 
together. This overcame a time lag we had 
prior to that in distributing the TexLink 
(TNC-2) revision when revisions were made 
to the NCP version. 


Version 1.72 has just now left the testing 
stage and is being installed throughout the 
network. It is one of the biggest revisions to 
TexNet in years. It will soon be in 
distribution through TPRS and TAPR 
libraries. Here is an overview of what this 
software does. 


1. TexNode. There is a brand new 
TexN ode service. This is a local node, which 
is a connected alternative to digipeating. It 
fills in a gap in TexNet which allows stations 
which can both hear and work TexNet on 
the same node (not necessarily on the same 
physical port or frequency) to work each 
other without digipeating through the node. 
The TexN ode is accessed by connecting to 
the node's -1 SSID, which is new. The 
TexNode is still new and experimental. It 
may have some problems with flow control. 
Experience and use will show what its 
shortcomings are and how to solve them. It 
will probably need to be fixed at the next 
opportunity for a revision. 


The TexNode provides three pairs of 
connects for locals to use to connect to each 
other, without the drawbacks of digipeating. 
Please note that digipeating was originally 
invented in the early days of AX.25 as a 


temporary stopgap to produce some 
extended range connectivity while waiting 
for layer 3 networks to appear, which of 
course, they have now. Digipeating has 
drawbacks which have been discussed 
many times, and has been discouraged or 
locked out in some places [3]. 


There are a few nodes on TexN et which 
do not support digipeating for local QSOs, 
and as this local node service is expanded 
(and any bugs fixed) there will probably be 
more digipeating discouraged or locked out. 


2. Weather Alert. There is a weather 
alerting service which is allied to the 
Weather PMS. A PMS, or packet message 
server, iS a message server integrated within 
TexNet, and will be explained later. The 
Tulsa PMS is now generating a UI! broadcast 
on most of the NE Oklahoma TexN et ports 
every time a type “S” or severe weather 
message is saved to disk from the N ational 
Weather Service (NWS) input. 


The UI that is sent on all ports of the 
network includes a bell, and includes the 
heading, and the first few lines of the 
message - enough to determine the 
counties of interest. It is sent from an alias 
callsign of “ARES”, and anyone wanting to 
monitor these can put ARES into their 
Budlis t. 


These broadcasts can also be initiated 
manually by a station with sysop privileges, 
such as a net controller to announce a net 
activation. The network can be internally 
partitioned to limit the geographical 
distribution of these broadcasts. Presently 
the only partition is at the Red River into 
Oklahoma. 


There has been some addition to the 
Weather PMS input handling, and it is now 
feasible with standard code to upload the 
raw weather source from one site to another, 
where a PMS can be located remotely from 
the source, or to relay input data from one 
PMS to another. When we consider sites for 


weather PMS input, this feature needs to be 
considered. It is possible now to use a 
TexLink node (the TNC-2 with a TexNet 
EPROM) to act as the uploading input node, 
whether or not it has a disk drive. Of course, 
the standard NCP or possibly the NCP-PC 
may be used. Presently, there is some fairly 
widespread investigation behind the scenes 
to acquire more weather input sources, 
using the highly successful TULWX Tulsa, 
Oklahoma site as a model [4]. The Texas 
network went through spring storm season 
without a Texas weather PMS, as we lost that 
site at a critical time 


3. New Internal Datagrams. There are a 
few new internal datagrams to support new 
functions within the network, and one new 
network information code, NIC-22, which 
users may encounter from time to time 
during routing errors. 


This particular error comes about as a 
result of a datagram propagating through 
the network and encountering a node which 
has no knowledge of the return routing for 
that datagram. It now generates an error 
which returns on the same channel it was 
received on, directed back at the source, 
while the return channel is still known. 
Previously, there was no check, and a 
deadlocked condition existed when the 
response could go no farther on the return 
trip. In addition to the error completing the 
“response,” the receipt of the error 
automatically issues a routing correction to 
the node finding the error to begin with, so 
that subsequent uses of that route will be 
successful. 


This release adds some major internal 
modifications and tuning to the basic 
routing. The routing methods themselves 
are unchanged, but it is much easier for the 
routing manager (i.e. Harry) to maintain the 
system. He now has the capability to edit 
any route table, whereas he used to either 
use a sledgehammer approach, or execute 
cumbersome memory changes. The release 
also addresses the root cause of many of the 
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routing corruptions, the unwanted trunk 
paths during band openings, by limiting the 
formation of such paths in the first place 
When 1.72 is fully installed over the 
network, expect that there will be fewer 
corruptions.-The ones that do occur will be 
mucheasier for Harry to fix, so the network 
should run better more of the time with less 
of his attention. This software also 
implements a remote function needed by the 
automated NetM gr (a Cardnal function) to 
perform automated routing management in 
the future. 


41 Remote User Listing. There is now a 
Remote Users listing command. It displays 
the stations connected to a remote node 
(presently it does not support the local ncp), 
and displays some numeric information 
which can be decoded to reveal which L3 
service the user, or trunk, is on, what the L2 
state is, and some allied information. It 
displays both users and other connected 
trunks. It is useful to both users in general 
to find out who is on any node and to 
network sysops to determine the status of 
trunks. 


5. Improved Local Console. For those 
node operators who have terminals installed 
on the local port of the node, the terminal 
port has changed from 7E! to 8N1, and some 
bad behaviors of the Console program have 
been fixed. The input line will no longer 
force back to command mode if too long a 
line is typed. PTRACE has been extendevd a 
little bit to include hex dumps of some of 
the datagrams, recognition of NetMgr 
datagrams, and a bad bug fixed which 
locked up the works from time to time. For 
those operators who have their node 
implemented on an NCP-PC card, the 
console port may be operated over the bus 
instead of through the serial port, via a 
supplied INT14 TSR. 


6. New Stats Display. Information has 
been added to the node statistics display and 
the format is completely different, and does 
allow for it to fit on a screen. However, an 


unfortunate result occurred and the date 
now appears in an insane format. Due to 
code space problems, I'll apologize 
beforehand for the unfortunate result. With 
the exception of the screwy looking time/ 
date, it is a lot easier to read. Added 
information includes TX frames aborted, the 
revision level of the software of the node, 
the CPU effective speed raw data, aROM 
checksum and the dates/ times of initial 
powerup and subsequent firecode and 
warm boot restarts of the node. One good 
result is that no longer does one have to 
multiply some numbers by 10; they are 
displayed with a trailing zero so you only 
have to read the number. Another good 
result is that the amount of program 
memory occupied by the statistics routine 
was cut in half and left room for some of the 
new features of this release. 


7. Network Path Locking. The algorithm 
implemented in ~1.72 follows a general 
trend that has been seen in other packet 
networks of route locking, or more 
accurately called PATH locking. The 
routing tables in each node are available at 
all times for updates by the shortest path 
algorithm. What is locked out is the 
formation of temporary shorter paths at 
layer 2. This would seem to be at odds with 
a system developed over the years for 
automatic addition of new nodes to the 
network. To allow for the addition of new 
nodes (or old nodes out of service for an 
extended time), there is a way around it - 
the 15 minute timer. Since v1.6x, all nodes 
broadcast their existence to the world every 
8 minutes, inviting any TexNet node hearing 
the broadcast to connect, new nodes or old 
nodes, close or distant. An exclusion list of 
up to 5 nodes is sent along with the invite 
If the two nodes are not on the exclusion list, 
~1.6~ allowed the connect to be made 
whether it was 500 feet or 500 miles. 
Whether the nodes were intended neighbors 
who had briefly lost connection, or distant 
and unrelated to each other, was irrelevant. 
This scheme has done a good job of 
maintaining the integrity of the connections 


we wanted, but also opened up a lot of 
transient rogue paths during band openings, 
often short-circuiting the distance counts in 
the tables by 5 or 10 hops, which destroyed 
the intended stable routing. Version 1.72 
now excludes new paths which are not 
shown as direct neighbors in existing 
routing. The exclusion is inactive for 15 
minutes after a node is reset and started UD. 
The 15 minute timer may also be started and 
stopped remotely by an existing manual 
remote control command. This is one of the 
means by which a new node can be added 
to the network. The other means is to 
manually insert the required entry in the 
table. 


Network Code Testing and 
Future Directions 


This software was extensively tested in 
ALAMO, one of the highest traffic nodes on 
the system, for a couple of months prior to 
releasing it. Thanks to Harry Ridenour, 
NOCCW, and Clarke Diekmann, K3WGF, 
and all of the local and remote users of 
ALAMO who got bumped off in the process 
of debugging, for seeing the process 
through. ALAMO was chosen because it is 
easily accessible to swap eproms, in addition 
to being a high traffic node, and also to give 
Harry the earliest access to the new route 
editing functions. It was also tested on 
TULWX and neighboring nodes in NE 
Oklahoma. As of July 8, it was installed in 
ALAMO, SANTEX, SALAMO, FLORES, 
ALICE, WACO, TULWX, LROCK, 
MAGAZIN, FTSMITH, CLAYTON, 
FTGIESN, MUSKOGE, MKO’IST, DENTON, 
SHERMAN ,MURI’HY,GREENVL,AUSTIN, 
AUSDXC, and GERONMO, and is ready for 
afew more. | have emailed a copy of it to 
Jay Nugent for GL-NET to start using. 


This software is available in both NCP and 
TNC-2 versions, as were 1.70 and 1.71. In 
addition, it is easily adaptable to creating a 
specialized weather PMS, such as TULWX, 
without many changes other than preparing 
the weather product database. Previously, 


a weather PMS became almost a separate 
programming task, and this is less true now. 
Asin 1.70 and 1.71, the software supports 
90 nodes per network. | estimate that | spent 
300 to 400 manhours on this release and it 
was a major undertaking. Some of the route 
management improvements are items | have 
been thinking about for the past four years 
or so,, aS | have watched the network routing 
get corrupted mysef, and listened to Harry’s 
observations also. Most of the weather PMS 
improvements came out of a meeting held 
at the Green Country Hamfest in 1994 and 
some more came from Steve Piltz and Brad 
Smith in Tulsa. 


| have plans for a subsequent version. 
Some of the revisions | would like to add 
would require that all Eproms on the 
network prior to 1.72 be replaced with 1.72, 
since | foresee some incompatibilities being 
made. My biggest reason to want to get 1.72 
installed quickly is to solve our routing 
corruption problems, and those sites 
experiencing unnecessary trunk connects 
during openings are the prime priority. The 
downside to future code devdopment is that 
about 30 bytes of space is left in the NCP 
Eprom, so there isn’t a lot to work with. 
Some space will come from shrinking 
existing programs by either eliminating 
lesser used functions, or from time 
consuming recoding to make the code 
shorter. Some of the new features have 
actually been implemented by 
programming tricks which resulted in 
shorter code. There are also efforts 
underway to integrate and/ or supplant this 
code with a TCP/ IP interface to extend the 
range and the lifetime of the existing and 
growing network. 


Network Code Development 


The code itself is written in multiple linked 
modules of Z80 assembly language, using a 
native CP/ M assembler/ linker running as 
a CP/M program under ZSOMU,, which is a 
280 emulator and CR/ M emulator running 
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under DOS on a PC. A complete assembly 
and link process can be performed in about 
20 minutes on a fairly fast 386 system, 
producing a generic binary load of either the 
NCP or the TNC-2 code We then use an 
editing process to perform a binary edit to 
customize an image for any particular node, 
to add its callsign, net ID, parameters and 
so forth, and all of that is burned into an 
eprom. Except for abnormal operating 
conditions, no further entering of 
parameters is required after the node is 
started up. 


The NW-PC and NetM gr Projects 


The NCP-PC project continues, although 
no more kits are planned. The NCP-PC is 
an |/ O card for the PC, which includes the 
cou section, less modems, of the TexNet Z80 
NCP, and behaves as a very loosely coupled 
coprocessor. It behaves as an EPROM to the 
280, since writes are inhibited from the 280 
for that portion of the memory map. It is 
entirely RAM and can bewritten by the PC 
at random. It makes a fine development 
system, since the steo of EPROM burning is 
not needed. All of versions of 1.6x and 1.7x 
were developed using a NCP-PC. While it 
doesn’t emulate a TNC-2, the only 
differences between the TexNet NCP and 
TNC-2 code are the number of serial ports, 
differing addresses, differences in the 
memory boundary between EPROM/ RAM, 
and the presence of a CTC chip on the NCP 
or NC&PC. These differences are allowed 
for in the conditional assembly of the 
standard software suite for both products. 
When acceptable code for the NCP is 
achieved, the conditional assembly is rerun 
for the TN C-2 product, and burned into an 
EPROM and tested conventionally in a 
TNC-2, usually with no surprises. The 
TNC-2 code has in fact been released in 
finished form under 1.70, 1.71 and 1.72 
without further modification. 
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The automated NetMgr (Network 
Manager), a NCP-PC project kept on line 
co-located at the Murphy node (the town of 
Murphy, Texas, not the errant destroyer of 
mankind’s engineering achievements by the 
same name) continuously monitors and logs 
network activity. This information is then 
analvzed to determine potential network 
problems. There has bien slow progress 
made on the automated route management 
R&D phase of this project. The release of 
~1.72 added a needed inquiry function to 
help facilitate that project. The eventual goal 
of the project is to have all automated route 
management handled by the Network 
Management system. The statistics it 
generates enables better manual routing 
maintenance to be performed, than would 
be possible were the statistics not available. 
In defense of the goals of automated 
NetMgr, it should be noted that the energies 
of the developer (Tom McDermott, N SEG) 
were diverted to not one, but two DSP 
projects. The first being the TPRS DSP land- 
line modem and the second one being the 
TAPR/ AMSAT DSP-93 project. The NetMgr 
is still functioning at ~1.6~ and there is some 
programming effort planned in the near 
future to bring this one node up to current. 
That is expected to be a minor job, but crucial 
to NetMgr’s operation. 


Network Administration 


The network still relies on human beings 
to perform network routing management 
manually. This job is being made easier 
under ~1.72 with a remote route editing 
command. This manual command makes 
use of some logic added in ~1.6~ to allow 
for the automated NetMgr to add and 
change routing remotely. At that time, we 
had no manual means to do so, other than a 
remote memory patch, or to selectively 
announce or reset nodes to reinitialize the 
autorouting. This follows the general trend 
of all automation, that the human is still 
sometimes not replaceable, but some of the 


drudgery can be automated, leaving the 
human to take care of the exceptions. Goals 
in ~1.72 were to reduce some of the 
extraneous inputs which disrupt the routing 
in the first place, to give the human manager 
the editing command he needed, and to add 
the missing inquiry function that the 
automated N etM gr needed. Eventually the 
NetMgr can take over some jobs from the 
human in the future. It should be noted that 
we are blessed with a human net manager, 
Harry Ridenour, NOCCW, who spends some 
time every day watching over the network 
and seeing to its integrity. A lot of the things 
he does are not of the nature that can be 
automated. These include coordinating 
with site owners for site access, wire line 
troubleshooting, arranging new site 
installations, and handing out new node 
numbers. The new network remote function 
allows the network administrtor to easily 
change network routing information from 
anywhere on the network, thus creating 
more time to devote to other tasks. 


TexNet enjoys an environment of 
administered planning. Our administrator 
governs the distribution of node numbers 
to sponsors who fit into an overall plan for 
a network. It is not a network that expands 
and contracts on a cyclic or a whimsical 
basis. We know in advance when a node 
will be added or repaired, and can make the 
necessary commands to the system, to either 
preinstall the proper entry in a routing table, 
or start the timers at the proper time. We 
have learned very well not to bring up or 
reset new nodes during band openings, and 
if we have to, how to get the route tables 
into a proper state after we have done so. 
Version 1.72 will make this job a lot easier. 
We anticipate development of some 
automated NetMgr algorithms and eventual 
auto routing control. 


Other services provided by the 
CARDNAL node include a multiuser file 
server, an amateur callsign lookup database 
based on a CD-ROM callbook, an ARRL 


bulletin capture system based on reception 
of the AMTOR-FEC bulletins (retaining the 
most complete recent copy), and a network 
wide conference bridge. The file server is 
also the delivery vehicle for the ARRL 
bulletins and the NetMgr statistics files, in 
addition to other files loaded to the system 
by the users or the host. 


Other TPRS Projects 


TexNet has several donated land line 
circuits that make up some of its routes, 
although TexN et is primarily an amateur RF 
based network. We have access to 200+ 
miles of point to point circuits which are 
used, from various land line commercial 
providers, for nothing but our good will, a 
smile, and probably our tax exemption 
number. 


Land-line circuits are an integral part of 
the network, since ninety miles on a calm 
damp evening is the best intermittent RF 
circuit we can boast of, or 65 miles if you 
want a “reliable” RF circuit. Without these 
long-haul paths in the network, several 
sections would be unattainable as network 
paths (i.e trying to find enough amateurs 
between Austin/ Dallas/ San Antonio and 
the West Texas cities to support nodes). 


Surplus GDC 209 synchronous modems 
are used to drive these land line circuits. 
Due to reiability problems with the GDC 
modems, a project was started to design a 
modem that would give us the necessary 
interface as well as provide. needed 
monitoring and testing functions. Tom 
McDermott, NSEG, set about to solve two 
problems with this modem with a 
replacement based on current DSP 
techniques. The first goal was to put a 
reliable modem into service. The second 
goal was to speed up the circuits we were 
using them on, because the 209 standard has 
an abysmally long training sequence which 
it must perform on each transmission of a 
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multidropped circuit. While it is 960Obaud, 
the txdelay required to support the modem 
training sequence is about 400 mS. In most 
cases, this is longer than the packet itself, 
and certainly so for the acks and supervisory 
packets. These circuits have a real 
throughput problem even when the 
modems are in good shape. Tom has 
designed and tested a prototype 
replacement which will emulate the 
constellation of the 209, and can either 
emulate the training sequence, or use an 
abbreviated training sequence which is 
based on recognition of previous recent 
transmissions of the various modems 
operating together on the circuit. The design 
includes remotely commanded diagnostics 
and remote level adjusting software, 
designed to work on an entire circuit of 
modems from onlv one end. These remote 


Conclusion 


TPRS and TexNet are alive and well and 
continue to develop and expand. We hope 
to be able to update their status many more 
times in this venue in the years to come. The 
success of the design of TexNet can be 
attributed to: higher speed trunks, separated 
user and trunk channes, low network-ip 
overhead, low installation cost per port, tight 
trunk bandwidth with low error rates, 
network planning/ administration, and 
multiple applications available via the 
network to the user population. 
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